Communications systems evolve more and more towards an Internet Protocol (IP)-based network. They consist of many interconnected networks, in which speech and data is transmitted from one terminal to another terminal in pieces, so-called packets. Those packets are routed to the destination by routers in a connection-less manner. Therefore, packets consist of IP header and payload information and the header comprises among other things source and destination IP address. For scalability reasons an IP network uses a hierarchical addressing scheme. Hence, an IP address does not only identify the corresponding terminal, but additionally contains location information about this terminal. With additional information provided by routing protocols, routers in the network are able to identify the next router towards a specific destination.
If a terminal is mobile, from now on called Mobile Node (MN), and moves between subnets, it must change its IP address to a topological correct one because of the hierarchical addressing scheme. However, since connections on higher-layers such as TCP connections are defined with the IP addresses (and ports) of the communicating nodes, the connection breaks if one of the nodes changes its IP address, e.g., due to movement.
Mobile IPv6 [D. Johnson, C. Perkins, J. Arkko, “Mobility Support in IPv6”, IETF RFC 3775, June 2004] is an IP-based mobility protocol that enables MNs to move between subnets in a manner transparent for higher layers and applications, i.e. without breaking higher-layer connections. Therefore, a MN has two IP addresses configured: a Care-of-Address (CoA) and a Home Address (HoA). The MN's higher layers use the HoA for communication with the communication partner (destination terminal), from now on called Corresponding Node (CN). This address does not change and serves the purpose of identification of the MN. Topologically, it belongs to the Home Network (HN) of the MN. In contrast, the CoA changes on every movement resulting in a subnet change and is used as the locator for the routing infrastructure. Topologically, it belongs to the network the MN is currently visiting. One out of a set of Home Agents (HA) located on the home link maintains a mapping of the MN's CoA to MN's HoA and redirects incoming traffic for the MN to its current location. Reasons for having a set of HAs instead of a single HA are redundancy and load balancing. The data communication session between a specific CN address and a specific MN HoA is called a Mobile IP data session.
Mobile IPv6 currently defines two modes of operation: bi-directional tunnelling and route optimization. If bi-directional tunnelling is used, data packets sent by the CN and addressed to the HoA of the MN are intercepted by the HA in the HN and tunnelled to CoA of the MN. Data packets sent by the MN are reverse tunnelled to the HA, which decapsulates the packets and sends them to the CN. For this operation, only the HA must be informed about the CoA of the MN. Therefore, the MN sends Binding Update (BU) messages to the HA. These messages are sent over an IPsec security association and thus are authenticated and integrity protected. Since the CN is not aware of the CoA of the MN, it cannot derive the location of the MN and, thus, location privacy is provided. However, if the MN is far away from the home network and the CN is close to the MN, the communication path is unnecessarily long, resulting in inefficient routing and high packet delays (see FIG. 1).
Recently, Mobile IPv6 has been extended to enable MNs to dynamically bootstrap with HAs [G. Giaretta, J. Kempf, V. Devarapalli, “Mobile IPv6 bootstrapping in split scenario”, draft-ietf-mip6-bootstrapping-split-02.txt, March 2006]. Bootstrapping includes discovering a HA, configuring a corresponding HoA, and setting up IPsec security associations with this HA. Since manual configuration of mobile nodes is neither practical and nor scalable, it can be assumed that Mobile IPv6 will be deployed with the bootstrapping extension, especially in large scale deployments. The bootstrapping extensions enables a MN to bootstrap with a local HA to optimize the route in bi-directional tunnelling mode. However, this potentially breaks location privacy support, since the HoA (which is usually known by CN) now contains location information. For instance, if the CN knows that the HA is local to the MN (e.g., it is the operator's policy to bootstrap with local HAs), it can deduce the MN's location based on the MN's HoA. Furthermore, changing the HA by bootstrapping requires changing the HoA, which means that ongoing data sessions would break. Hence, route optimization of ongoing data sessions is not supported.
Note that different aspects of location privacy can be distinguished. The one this invention aims at is hiding the MN's location to the CN. Other aspects are hiding the location to eavesdroppers or preventing tracking of the MN's location.
The route optimization mode can prevent the inefficiency of bi-directional tunnelling mode by using the direct path between CN and MN (see FIG. 1). Therefore, the MN sends BU messages to the CN, which then is able to directly send data packets to the MN (a type 2 routing header is used to send the packets on the direct path). Of course, the CN has to implement Mobile IPv6 route optimization support. To authenticate the BU message, the MN and the CN perform a so-called return routability procedure, which tests the reachability of the MN at the HoA and CoA and generates a shared session key (see below). However, since the CN learns the CoA of the MN by means of the BU message, it can derive its location, i.e. location privacy is not provided.
In the following, prior art documents that can provide route optimization or location privacy to some extent are discussed and the drawbacks of those solutions shown.
HMIP [Hesham Soliman, Claude Catelluccia, Karim El Malki, Ludovic Bellier, “Hierarchical Mobile IPv6 mobility management (HMIPv6)”, IETF RFC4140, August 2005] was developed to reduce the latency and signalling overhead occurring due to sending BU messages to a (potentially far away) HAs. It is proposed to handle the mobility partly locally. Therefore, a hierarchy of Mobility Anchor Points (MAP) is introduced in the visited network. The MN only needs to register its CoA with the local MAP. An additional CoA, the so-called Regional CoA (RCoA), is obtained from the MAP's subnet and used by the MAP to hide the MN's mobility within the MAP's region from the HA (or the CN in case of route optimization). Furthermore, MN can start Route Optimization mode using the RCoA as CoA. Hence, some support for simultaneous route optimization and location privacy can be provided, but since CN still knows the RCoA and hence the MAP region the MN is currently located in, location privacy support is very limited.
AREC [WO2004055993; as well as G. Krishnamurthi, H. Chaskar, R. Siren, “Providing End-to-End Location Privacy in IP-based Mobile Communication”, IEEE WCNC, March 2004] requires modification of every Access Router (AR) of every visited network. Binding information is sent from HAs to ARs of the CN and MN, respectively, and data packets are tunnelled between the ARs of MN and CN without involvement of the HAs. This way, the direct, i.e. shortest, route between MN and CN is used and location privacy is supported. In WO2004010668 a very similar approach is presented. However, security issues arise due to the dissemination of binding information to ARs and the distribution of binding information from the HAs to the ARs requires a new complex protocol, which would have to be standardized and which would have to be universally deployed to be useful.
ORC [Ryuji Wakikawa, “Optimized Route Cache Protocol (ORC)”, Internet Draft draft-wakikawa-nemo-orc-01.txt, October 2004] was developed for route optimization in mobile networks (NEMO) and requires modifications to edge routers of visited networks, including the provision of binding information. The MN tunnels data packets to the edge router of CN's current network (assuming that CN is mobile) and the CN can tunnel data packets to the edge router of MN's current visited network. To be able to tunnel the packets to the edge routers, each node needs to know the IP address of the correspondent edge router. Security issues arise and a new protocol has to be standardize, which would have to be universally deployed to be useful. Furthermore, simultaneous location privacy and optimized routing is only supported, if the modified edge router is deployed in CN's network and if this router is located on the direct path between MN and CN.
GlobalHAHA [P. Thubert, R. Wakikawa, V. Devarapalli, “Global HA to HA protocol”, IETF Internet Draft draft-thubert-nemo-global-haha-00, October 2004] allows the distribution of HAs in the Internet that are usually bound to the home link by letting multiple HAs advertise routes to the home network prefix from different topological locations. A MN can bind to the closest HA, which serves as proxy HA, resulting in an optimized route. Location privacy is given, if bi-directional tunnelling is used. Hence, simultaneous route optimization and location privacy is provided. However, if all visited network advertise routes to all other networks (all being home networks for some MNs), routing scalability issues may arise, since the address hierarchy is basically not given anymore. Furthermore, the distributed home network must manually be configured as such. A secure on-demand configuration is not supported and would require a new complex protocol, which would need to be standardized and would have to be universally deployed to be useful.
In WO03041358 so-called Location Privacy Agents (LPA) and Location Privacy Servers (LPS) are introduced in every network. The MN sends a location privacy request message to its LPA, which then selects an LPA that is close to the CN. The address of this LPA is then given to the MN, which then sends a BU message to this LPA. Hence, the approach is similar to the ORC approach: since the LPA is close to CN's network, it knows the location of CN to some extend, which breaks location privacy support if the CN is mobile. Moreover, this solution would require a new signalling protocol and introduces new entities.
In US2005041675 and WO2004043010 location privacy is achieved by cryptographically modified prefixes of IP addresses. Since the prefix is usually used by a router to route IP packets, this approach requires the modification of all routers in the Internet, which is not a realistic option, or can only provide very limited location privacy.
In WO03044626, multicast addresses are used as CoA. Since they do not include any location information, location privacy support is given even in route optimization mode. However, this solution does not scale with the number of MNs, since a large-scale deployment would result in a flat routing in the Internet.
Mechanisms such as proposed in US20040236937 only deal with hiding the MN's identity and hence also location from eavesdroppers. It cannot hide the MN's location from CN and hence doesn't solve the given problem.
In J. Zhang and D. Pearce (“Agent-Based Return Routability Test for Mobile IPv4 Route Optimization”, IETF Internet Draft draft-zhang-mobopts-agent-mip4rr-00.txt, August 2005), it is proposed to adopt the MIPv6 route optimization scheme for MIPv4 route optimization. A Correspondent Agent (CA) is introduced that proxies the CN in terms of return routability. This way the CN implementation does not need to be modified and data packets can directly be tunnelled between MN and CA. A side effect of the CA is that MN's location is hidden from CN. This approach is similar to ORC. Hence, security issues arise, a new protocol has to be standardized, and a CA has to be introduced. Furthermore, simultaneous location privacy and optimized routing is only supported, if a CA is deployed in CN's network and if this CA is located on the direct path between MN and CN.
Finally, C. Castelluccia, F. Dupont and G. Montenegro (“A Simple Privacy Extension for Mobile IPv6”, draft-dupont-mip6-privacyext-02.txt, July 2005) propose to replace the HoA by a Temporary Mobile Identifier (TMI). If the MN initiates the session, it can thus hide the HoA from CN and only reveal the TMI. Although CN learns the MN's CoA, it doesn't reveal the MN's location since CN doesn't know the real identity corresponding to the CoA. However, for the CN to be able to initiate communication with the MN, the CN must know the MN's HoA and hence location privacy is not provided in such scenarios (note that the HoA cannot be changed to keep higher-layer sessions alive).
Often, communication session establishment requires signaling on the application layer. A popular protocol that is used for this purpose (e.g., by VoIP applications) is the Session Initiation Protocol (SIP) (J. Rosenberg et al, SIP: Session Initiation Protocol, RFC3261, June 2002). An example of session establishment signalling using SIP between a MN and a CN is shown in FIG. 10. The example shows a simplified signalling flow for the sake of clarity. If, for instance, IMS (IP Multimedia Subsystems) is used, more signalling messages are sent, e.g. for resource reservation and charging reasons.
SIP defines new infrastructure entities: Each SIP node has assigned a SIP registrar or proxy server, to whom it is registered and to/from whom it usually sends/receives SIP signalling messages. To establish a session with a CN, the MN sends an Invite message to its proxy server. The Invite message contains a description of the session, such as media type, transport protocol, addresses and ports for the session. The Invite message must also contain the SIP Unified Resource Identifier (URI) of the correspondent node. The SIP URI could, e.g., be “Bob@domain.com”. The description is usually carried by the Session Description Protocol (SDP) [M. Handley et al, SDP: Session Description Protocol, RFC 4566, July 2006]. SDP in SIP follows an offer-answer-model, which means that one node offers media type, codecs etc., and the other node accepts or rejects the offer. SDP offers and answers can be appended to various SIP messages. MN's proxy server discovers proxy server of CN using the SIP URI and DNS and sends the Invite message to this proxy. CN's proxy knows CN's address from a previous registration message sent by CN and forwards the Invite message to CN. The receipt of this message triggers a notification of the user, e.g., by a ring tone. At the same time, CN sends a notification back to MN, which is routed on the reverse path over the proxy servers. When the user picks up the call, CN sends an OK message back to the MN. The SDP answer, which also includes the CN address, can be appended to any of the reply messages, e.g., the Ringing or the Ok Invite message. Furthermore, the contact field in the SIP header may contain the address of the sender endpoint. In any way, once the Ok Invite message is received, the addresses of the endpoints are known and the MN can start sending data to CN and vice versa without going over the proxies.
Efficient interworking of Mobile IP and application-layer signalling such as SIP is a problem on its own. Several solutions have been proposed, which are described in the following.
In WO2005046132 and EP1680894, an optimized operation of a system supporting both Mobile IP (MIP) and SIP is proposed. The basic idea is that the MN registers its HoA at the SIP server and that the MN informs the CN about its HoA by putting it in the contact field in the SIP header. Consequently, data corresponding to the SIP session is routed to MN's HoA and can be delivered to the MN even when the MN has moved. Furthermore, no SIP signaling is required on network-layer handovers of the MN.
US20040165594 describes a method for optimized inter-working between Mobile IP and SIP, when Mobile IP route optimization is used. The idea is to trigger Mobile IP route optimization already during the SIP signaling flow, more specifically when the MN learns the address of the CN from received the SIP messages. Due to this cross-layer trigger from application-layer to network-layer, SIP and MIP route optimization signaling can occur at least partly concurrently and the optimized route may already be available for the first data packets, i.e., when the data session actually starts. However, since Mobile IP route optimization is used, location privacy cannot be provided by this method EP1605662 proposes a method for route optimization in a MIP-SIP-inter-working scenario. Therefore, the MN registers both its HoA and CoA after a handover at the SIP server. Furthermore, the CN is informed about both addresses. This enables the setup of tunnels between CN and FA (Foreign Agent) and SIP server and FA or between MN and SIP server and MN and CN for optimized routing. However, this approach cannot provide location privacy and requires changes to FAs and SIP servers.
GB2412543 also considers the interworking of MIP and SIP. Here, it is proposed that the MN is triggered to register a new address at the SIP server after MIP or FMIP has detected a handover.
WO2001072007 propose that the MN will be paged by the network once a SIP Invite message for the MN sent by a CN is received at the SIP server. Next, the MN gets assigned an IP address and, finally, the SIP Invite message is delivered to the MN for establishing the session with the CN. Consequently, the state the network needs to maintain state about the MN's location is significantly reduced as long as the MN has no active communication sessions.
A mechanism that provides both location privacy and optimized routing is certainly desirable, since interactive applications such as VoIP require short packet delays. The mechanism should require only small changes to Mobile IPv6 message formats and implementations of Mobile IPv6 entities. Furthermore, it should support scenarios where the MN initiates the communication session as well as where the CN initiates the session.
The main problem to be solved is to hide the MN's location from CN and at the same time provide optimized routing of data packets. This shall be possible for communication sessions initiated by MN as well as by CN and shall only require minimal changes to Mobile IPv6. Moreover, location privacy support shall be unlimited, i.e., it shall neither be possible for the correspondent node to derive the link, nor the network or the domain, where the mobile node is currently located. The protocol and tunnelling overhead over the air and in the network is potentially large and an efficient way has to be found to support SIP-based services.